[pull] master from supabase:master - #1126

<!-- ccr-slack-attribution -->
_Requested by **Nicole Kramer** · [Slack
thread](https://supabase.slack.com/archives/C0161K73J1J/p1785399344523739)_

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Content update — adds a new version of the Terms of Service to the
marketing site (`apps/www`).

## What is the current behavior?

`/terms` offers two versions in the version dropdown: **Version 2 (May
6, 2026)**, shown by default, and **Version 1 (July 11, 2025)**.

## What is the new behavior?

`/terms` shows **Version 3 (August 1, 2026)** by default. Version 2 and
Version 1 are still selectable from the version dropdown
(`/terms?version=v2`, `/terms?version=v1`) and are completely unchanged.

Two files:

- **New:** `apps/www/data/legal/terms/v3.mdx` — the full v3 Terms of
Service.
- **Changed:** `apps/www/pages/terms.tsx` — imports `V3` and prepends it
to the `versions` array. Newest-first ordering is required, because
`LegalDocVersions` treats `versions[0]` as the latest.

## Additional context

### The legal text is a verbatim transcription — please review it as
such

It comes from a Word document supplied by Legal, converted with pandoc
and then verified character-exact against the source: **8055 words, 136
blocks, 0 word-level diffs**. Prettier was run over the file and changed
nothing.

**Known typos in the source document were deliberately preserved. Please
do not correct them in review:**

- §1 Definitions contains a **duplicate `d.`** — one `d.` introduces the
Data Processing Addendum definition and the very next item is also
lettered `d.` for the Documentation definition. The list therefore runs
a, b, c, d, d, e … Re-lettering would shift internal cross-references,
so it is left exactly as drafted.
- §12(d) Survival contains a **doubled “and”** — *and Sections 1, 5, 6,
8, 9, 10, 11, and 13, and 14 survive*.

Also preserved verbatim from the source: curly quotes on the Data
Processing Addendum definition only (every other defined term uses
straight quotes), and non-breaking spaces around the hyperlinks.

### Date

The source document carries **no date line of its own**, even though its
§14(d) states that the last-modified date *will be updated at the top of
this Agreement*. August 1, 2026 was specified by the requester, and is
placed in the `_Last Modified: 1 August 2026_` line at the top of the
MDX, following the v1/v2 convention.

As with v1 and v2, the `.mdx` uses `D Month YYYY` while `effectiveDate`
in `terms.tsx` uses US long form (`August 1, 2026`). That split is
pre-existing and intentional.

### New DPA link

§1 of v3 links the Data Processing Addendum page at
`/legal/customer-resources/data-processing-addendum`. This link is new
relative to v2, and the DPA is also incorporated by reference in §7(b).

### No overlap with the concurrent DPA branch

This PR touches only `apps/www/data/legal/terms/v3.mdx` and
`apps/www/pages/terms.tsx` — **zero file overlap** with the branch
updating the DPA page dates.

### Reviewer checklist

- 14 numbered sections (1 Definitions → 14 Miscellaneous), 44 lettered
subsections, 6 roman sub-subsections.
- ALL-CAPS acceptance block at the top; ALL-CAPS AI disclaimer at the
end of §9(b); ALL-CAPS §11 Limitations of Liability.
- Three link targets intact: the DPA page,
`https://supabase.com/privacy`, and `mailto:legal@supabase.io` (×3).

Co-authored-by: Claude <noreply@anthropic.com>

<!-- ccr-slack-attribution -->
_Requested by **Nicole Kramer** · [Slack
thread](https://supabase.slack.com/archives/C0161K73J1J/p1785399555203219)_

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Content update — a new version of a published legal agreement.

## What is the current behavior?

The version selector on `/enterprise-terms` offers two versions of the
Enterprise SaaS Subscription Agreement: Version 2 (May 6, 2026) and
Version 1 (April 17, 2026). Version 2 is what the page shows by default.

## What is the new behavior?

**Before:** opening `/enterprise-terms` showed Version 2 — May 6, 2026.
**After:** it shows **Version 3 — August 1, 2026**. Versions 2 and 1 are
unchanged and still reachable from the dropdown (`?version=v2`,
`?version=v1`).

Two files change:

- **New** `apps/www/data/legal/enterprise-terms/v3.mdx` — the Version 3
text, transcribed from the source Word document supplied in the Slack
thread (`2026.07.29 - Supabase - Enterprise Terms.docx`).
- `apps/www/pages/enterprise-terms.tsx` — imports the new MDX and
prepends `{ id: 'v3', label: 'Version 3', effectiveDate: 'August 1,
2026', Component: V3 }` to the `versions` array. Since the array is
newest-first, v3 becomes the default.

## Additional context

### Transcription fidelity

The legal text was not edited, reworded, reordered, or corrected — only
re-rendered in the MDX conventions already used by `v1.mdx` and
`v2.mdx`. This was verified mechanically rather than by eye: markdown
markup was stripped from `v3.mdx` and the result diffed
paragraph-by-paragraph against text extracted directly from the source
document's OOXML.

- **137 paragraphs in the source, 137 in `v3.mdx`, 0 differing.**
- 14 top-level sections and 48 subsections, matching the source's
heading counts exactly.
- All 3 distinct URLs preserved, written as bare URLs per the existing
convention in this file family (remark-gfm autolinks them).
- Pure ASCII apart from 5 `§` characters in the 48 C.F.R. citations,
matching `v1.mdx`/`v2.mdx`.
- Prettier clean; no British spellings that would trip the US-locale
misspell check.

Formatting decisions worth knowing: the source document contains no bold
or italic runs at all, but `v1.mdx` and `v2.mdx` both bold defined terms
and section numbers, so v3 follows that house style for consistent
rendering across the three versions. The source also carries no date or
version line of its own; the `_Last Modified: 1 August 2026_` first line
is repo convention, matching how every other legal MDX in
`apps/www/data/legal/` is written.

### What changed from v2, in the legal text

Structure is identical — same 14 sections, same 48 subsection titles.
Five substantive prose changes:

1. **Preamble** — the effective date is now "the date of last signature
of an Order referencing these terms", replacing v2's unfilled
`[Deal.CloseDate]` merge-field placeholder. "Signature block below"
becomes "signature block in an Order".
2. **New § 1.4 "Data Processing Addendum"** — defined by reference to
`https://supabase.com/legal/customer-resources/data-processing-addendum`,
with a carve-out for a separately executed agreement covering the same
subject matter. Former § 1.4–1.12 shift to § 1.5–1.13; nothing was
removed or reordered.
3. **§ 7.2 Data Processing** replaced — v2's GDPR / UK GDPR / Swiss
clause is gone, replaced by a general compliance paragraph that
incorporates the Data Processing Addendum into the Agreement.
4. **§ 13.3** cross-reference corrected from Section 10.1 (Mutual) to
Section 10.3 (Limited Warranty), which is the clause the refund remedy
actually depends on.
5. **§ 14.4 Amendment and Modification** rewritten — v2 required a
writing executed by both Parties; v3 gives Supabase a unilateral right
to modify by posting a revised version at
`https://supabase.com/enterprise-terms`, effective the first day of the
following calendar month, or at the start of the next Renewal
Subscription Period for Orders with a fixed Subscription Period of 12
months or longer, with non-renewal under § 13.1 as Customer's sole and
exclusive remedy.

Two things carried over verbatim from the source rather than fixed,
since the text must not be edited: § 7.2 is now near-duplicative of §
7.1 (three of its four sentences repeat § 7.1 almost word for word), and
"HIPAA" is used in both § 7.1 and § 7.2 without being defined.

One pre-existing inconsistency, unrelated to this change: `v2.mdx`'s own
first line reads `_Last Modified: 1 May 2026_` while the page lists
Version 2's effective date as `May 6, 2026`. Left alone here.

### Overlap with concurrent work

Two sibling changes are in flight for the same requester today — one
adjusting the new Data Processing Addendum page's dates, one publishing
Terms of Service v3. Neither touches these two files, but all three
touch the `apps/www/data/legal/` tree, and note that § 1.4 above now
links to the DPA page.

[#48483](#48483) removes the
`_Last Modified:` first line from every versioned legal MDX, on the
principle that the version selector should be the only place a date
appears. It is sequenced to land after this PR, and its file list
predates `v3.mdx`. A three-way merge of the two branches is clean, but
whoever rebases #48483 should add
`apps/www/data/legal/enterprise-terms/v3.mdx` to that removal —
otherwise v3 keeps a body date after v1 and v2 lose theirs.

The `_Last Modified: 1 May 2026` / `May 6, 2026` mismatch on v2 is also
handled in #48483 and is deliberately left alone here, so the same line
isn't touched by two PRs.

Co-authored-by: Claude <noreply@anthropic.com>

<!-- ccr-slack-attribution -->
_Requested by **Francesco Sansalvadore, Nicole Kramer** · [Slack
thread](https://supabase.slack.com/archives/C0161K73J1J/p1785399057853249?thread_ts=1785399057.853249&cid=C0161K73J1J)_

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Refactor of the marketing site's legal pages, plus two small content
fixes (removal of duplicated dates, two heading corrections) and two
permanent redirects.

## What is the current behavior?

The documents linked from the Legal Hub are built three different ways:

- `/terms` and `/enterprise-terms` render a plain inline heading with no
breadcrumbs.
- `/sla`, `/support-policy`, `/aup` and `/privacy` are standalone MDX
pages carrying their own layout.
- `/legal/dpa` has a one-off centered heading and grid of its own.

On top of that, the documents that already have a version selector
*also* print a "Last Modified" line inside the document body, so the
same fact is stated twice on the page. On `/terms` and
`/enterprise-terms` the two statements disagree: the selector says
"Version 2 — May 6, 2026" while the body says "Last Modified: 1 May
2026".

`/privacy` handles its history differently again — earlier versions live
at their own archived URLs (`/privacy-260316` and `/privacy-250528`),
strung together by "Previous Version" links at the bottom of each page.

## What is the new behavior?

Every legal page now renders through one shell: `PageHeader` with a
`PageBreadcrumb`, so the Legal Hub is one click away from any document.

- The duplicate "Last Modified" rows are removed from the five versioned
documents. The version selector is now the single place a date appears.
- `/aup` and `/privacy` gain the version selector.
- `/privacy`'s three historical versions are now selectable from the one
page, and the two old archived URLs permanently redirect to it.
- `/sla` and `/support-policy` pick up the shell and breadcrumbs but
intentionally show neither a date nor a selector — neither document has
ever carried one, and Legal asked that the SLA stay that way for now.

Implementation-wise the canonical pattern is the one the Data Processing
Addendum page was already using: `DefaultLayout` > `NextSeo` >
`PageHeader` (with a `breadcrumb` slot) > `MDXProvider` >
`SectionContainer className="prose"` > `LegalDocVersions`. The
standalone MDX pages were moved to `apps/www/data/legal/<slug>/vN.mdx`
as bare content partials, with a new TSX shell taking over the original
route. No route changed except the two archived privacy pages, which
redirect.

Dates were carried across from the "Last Modified" lines being deleted
rather than invented: `/aup` becomes Version 1 — June 1, 2026, and
privacy v1/v2/v3 become May 28 2025, March 16 2026 and May 13 2026.

## Additional context

**This is a stacked PR.** It is sequenced behind three PRs that touch
the same files and should land first: the Terms of Service v3 bump, the
Enterprise SaaS Subscription Agreement v3 bump, and #48481 (DPA
effective date → August 1, 2026). #48481 edits the very "Last Modified"
line this PR removes from the DPA content file, so a trivial conflict
there is expected. This branch will be rebased onto master before it
leaves draft.

**Two contracts now contain a clause that no longer describes the
page.** `apps/www/data/legal/terms/v1.mdx` and `v2.mdx` — and the same
sentence in the MPPA and both integration-partner addenda — still read
"The date on which the Agreement was last modified will be updated at
the top of this Agreement". There is no longer a date in the document
body; it sits in the version selector above it. Left untouched here
because it is contract text, but Legal should re-word it.

**The date mismatch is resolved in favour of the selector.** On `/terms`
and `/enterprise-terms`, deleting the body line leaves May 6, 2026 as
the only date on the page. Nicole Kramer confirmed in Slack that May 6
is the correct date.

**Two headings change visibly**, to line up with the labels used on the
Legal Hub: "Terms of service" → "Terms of Service", and "Service Level
Agreements" → "Service Level Agreement".

**`/legal/dpa` now looks almost identical to
`/legal/customer-resources/data-processing-addendum`** — same heading,
same breadcrumb, different content. The legacy page is a PDF download
plus a signing flow and was deliberately left live, but the overlap is
more obvious than it was. Redirecting it to the versioned page is the
natural follow-up; it is not done here.

**Build verification was incomplete in this environment.** `pnpm
install` could not finish because `npm.jsr.io` is blocked by network
policy (403), so `next build` never gave a real signal. What did run and
pass:

- `tsc --noEmit` on `apps/www`, with output byte-identical to clean
master
- ESLint on every changed file — 0 errors
- Prettier using the repo's actual config
- a direct MDX compile of all 14 `data/legal/**/*.mdx` files using the
app's own MDX options

The one thing left unverified is webpack resolving
`ui-patterns/PrivacySettings` from the privacy content's new directory.
CI will confirm that.

Co-authored-by: Claude <noreply@anthropic.com>

The [User Management → Deleting
users](https://supabase.com/docs/guides/auth/managing-user-data) section
warned that deleting a user does not sign them out, but did not say what
to do about it. Adds a **Removing account access** subsection: revoke
sessions before deleting, why a soft-delete flag or
[ban](https://supabase.com/docs/reference/javascript/auth-admin-updateuserbyid)
is not a substitute, and the residual [access-token
window](https://supabase.com/docs/guides/auth/sessions) after
revocation.

Fills a docs gap surfaced by
[supabase/agent-skills#194](supabase/agent-skills#194)
while investigating the
[`investigate-auth-001-deleted-user-access`](https://github.com/supabase/evals/blob/main/evals/investigate-auth-001-deleted-user-access/PROMPT.md)
eval scenario.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Updated the “Deleting users” guidance to specify deleting via
`auth.admin.deleteUser()` (with `shouldSoftDelete: false`) and clarify
that this cascades to sessions, invalidates refresh tokens, and blocks
new access-token minting.
* Rewrote the explanation to emphasize that it does not substitute for
temporary bans or application-level “deleted” states.
* Clarified the access-token window: already-issued stateless JWTs
remain valid until `exp`, and recommended mitigations include short JWT
expiry and enforcing session validation (via `session_id`) for sensitive
actions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Chores**
  * Updated Next.js, PostCSS, and tar package versions.
  * Added the required TypeScript native tooling where needed.
* Refined package configuration and dependency ordering across the
project.
  * Removed an unused empty dependency configuration.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

…8452)

## What

PR 6 of the SQL-editor "query source (Database vs Logs)" stack (builds
on the merged PR 5, #48414). Adds the user-facing toolbar surface for
the logs query source and consolidates the SQL-editor toolbar into a
single **source menu**.

Everything stays behind `sqlEditorLogsSource` + `otelLegacyLogs`
(dual-flag gated); with the flags off the toolbar is unchanged.

## Changes

- **Consolidated source menu** (`QuerySourceMenu`) — one `Database ▾` /
`Logs ▾` dropdown that both labels the snippet's source and hosts the
source-specific controls as flyout submenus:
- Database: database selector (`Primary` / read replicas), `Run as`
(role impersonation), and `Row limit`.
- Logs: `Time range` — the same relative presets as the Logs Explorer
plus a `Custom range…` calendar dialog.
- **Source is immutable** — the Database/Logs rows aren't a toggle. An
existing (materialized) snippet opens a *fresh* tab of the target source
(never reinterpreting a query against the wrong backend); a blank new
tab re-flavors in place. Extracted as the pure, unit-tested
`resolveSourceSwitch`.
- **New-snippet-with-source** threaded through `/sql/new?source=`, the
nav "Create a new logs query" entry, and the duplicate flow. Logs
snippets hide the (db-dialect) Export action.
- **Run-affordance guard** — the Run button is disabled + annotated for
a logs snippet on a non-ClickHouse org (sits above PR 5's execution
short-circuit).
- **Retention entitlement gating** — both preset and custom logs ranges
past `log.retention_days` surface the upgrade prompt instead of applying
silently. Prettify is disabled for logs (sql-formatter mangles
ClickHouse).

## Tests

- `querySource.test.ts` — `logDateRangesEqual` (structural
relative/absolute matching, incl. the "Last hour" vs "Last 1 hour" label
case).
- `QuerySourceMenu.utils.test.ts` — `resolveSourceSwitch`
push-vs-replace / no-op behavior.

`pnpm --filter studio typecheck` · `lint:ratchet` · Prettier · SQL
editor suite (307 tests) all green.

## For reviewers

To test manually, enable the `sqlEditorLogsSource` feature flag for
yourself on local/staging. There is no nav for Log SQL snippets
currently (that is by design, this PR is big enough as-is), so to check
an existing logs snippet, you can create one using the existing Logs
Explorer, copy its UUID, and force navigate to that snippet in the SQL
editor via URL.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Added support for creating and switching between database and logs
queries.
  * Added log time-range presets and custom date-range selection.
  * Added database, run-as role, and row-limit controls.
* Added read-replica selection, including options to create a new
replica when available.
* **Improvements**
  * Added clearer explanations when query execution is unavailable.
* Disabled SQL formatting and query export where unsupported for logs
queries.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Joshen Lim <joshenlimek@gmail.com>

…ugging (#48243)

## Summary

- Renames the **Telemetry** nav section to **Monitoring and Debugging**
(nav label + sidebar title)
- Rewrites the section overview (`telemetry.mdx`) as a clean navigation
page using `ContentListings` — three panels (Debugging / Monitoring / AI
& automation) with no how-to prose
- Adds new `telemetry.data.ts` content-listings data file with three
groups registered in `index.ts`
- Adds a new **Debugging** guide (`debugging.mdx`) — request-stack
model, symptom-to-layer router with troubleshooting links for every
service, logging guidance
- Adds cross-links between `debugging.mdx`, `logs.mdx`, and
`advanced-log-filtering.mdx`
- Adds a new **AI agents and MCP** page (`ai-agents.mdx`) — MCP tools
table, `get_logs` usage, debugging skill workflow
- Restructures sidebar into three groups: **Debugging** / **Monitoring**
/ **AI & automation**

## Motivation

- No central entry point existed for debugging — content was scattered
across products with no index
- The overview page had almost no links for agents to follow
- The section name "Telemetry" caused confusion (also used for CLI usage
telemetry)
- Unblocks the `supabase` debugging skill, which routes agents to this
section as its source of truth

## Test plan

- [ ] `/docs/guides/telemetry` — three ContentListings panels render, no
prose how-to text
- [ ] `/docs/guides/telemetry.md` (markdown) — clean link list,
navigable by LLMs
- [ ] `/docs/guides/telemetry/debugging` — renders correctly, symptom
table links resolve
- [ ] `/docs/guides/telemetry/ai-agents` — new page renders correctly
- [ ] Sidebar shows 3 groups: Debugging / Monitoring / AI & automation
- [ ] All cross-links between debugging, logs, and
advanced-log-filtering resolve


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

## Summary

- **New Features**
- Added new documentation coverage for AI agent–assisted monitoring and
debugging, including an observability-driven troubleshooting workflow.

- **Documentation**
- Updated the “Telemetry” area to “Monitoring and Debugging” with a
refreshed landing page and reorganized sections (Debugging, Monitoring,
and AI).
- Revised the debugging and logs guides to improve step-by-step guidance
and highlight advanced log filtering.

- **Navigation**
- Renamed and restructured the top-level navigation entry to reflect the
new Monitoring and Debugging content layout.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com>

…are not in view (#48454)

## What kind of change does this PR introduce?

There are some expensive queries that are requested every time the
Billing Settings page loads, some of them happen for components that are
outside of the initial viewport. We can avoid performing those requests
unless the user explicitly scrolls to the relevant section. A similar
pattern has been implemented in the past for the Credit Balance section
in #45481.

I decided to skip the lazy load pattern in the components that appear at
the top of the Billing Settings (Subscription and Cost Control).

## What is the current behavior?

When loading the billing settings page, all components (except
CreditBalance) will perform requests to load the data they need.

## What is the new behavior?

The components will perform the request to load their data until they
are inside the viewport. You can verify this by opening the developer
tools and monitor the requests as you scroll through the page.

## Testing

These changes can be easily tested by making your browser's height very
short then opening the org billing settings `/org/{slug}/billing`. Open
the developer tools and filter for XHR requests. As you scroll through
the page, the requests will be made.

To verify that all potential requests are covered, I compared the
requests done during a fresh load with another settings page, the only
extra requests made by the billing settings page are the ones relevant
to the components at the very top (or the BillingSettings container
itself, which requests the subscription).

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Performance Improvements**
* Billing, payment methods, billing customer details, upcoming invoices,
and invoice lists now load only when their sections scroll into view,
reducing initial loading.
* Existing access/permission checks are still applied before fetching
billing-related data.

* **Tests**
* Updated billing and invoices tests to mock viewport intersection
behavior (IntersectionObserver) to match the new lazy-loading behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

#48488)

PR description:

## Summary

- Clicking Feedback → Issue → Contact support was navigating to
`/support/new` (the old full-page form) instead of opening the
integrated sidebar support form
- Fixed by setting a `helpPanelState.requestedView` signal before
opening the Help sidebar, so it opens directly at the support form view
- Added a small valtio store (`state/help-panel-state.ts`) to
communicate the desired view between `FeedbackDropdown` and `HelpPanel`

## Test plan

- [ ] Feedback → Issue → Contact support opens the Help sidebar at the
support form (not `/support/new`)
- [ ] Help button → Contact support still works as before
- [ ] Closing and reopening the Help sidebar via the Help button opens
at the home view

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Selecting **Support** from the Help menu now opens the Help Panel
directly to the Support view.
* The Help Panel automatically updates to the requested section when
opened.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Fix the `<RadioGroupCard>` focus state design

Before:
<img width="676" height="117" alt="image"
src="https://github.com/user-attachments/assets/39849fd3-e6de-43dc-b4d7-67edcce3812d"
/>

After:
<img width="741" height="167" alt="image"
src="https://github.com/user-attachments/assets/13dad707-bc63-48da-8574-eb3d90b29625"
/>


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Style**
* Updated radio group card selection styling for a cleaner, more
consistent focus and checked-state appearance.
  * Added improved outline handling for radio group card items.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->